kotlin/openID4VP/src/commonTest/kotlin/io/mosip/openID4VP/jwt/jwe/encryption/EncryptionProviderTest.kt (1)

57-69: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Test locks in the swapped-argument bug from EncryptionProvider.kt instead of catching it.

The comment at line 63 explicitly acknowledges the bug ("Current implementation populates class name as the exception message"), and the assertion at line 66 asserts expectedMessage = "EncryptionProvider". Once the root-cause fix in EncryptionProvider.kt (swapped JweEncryptionFailure args) is applied, this test needs updating to assert the correct descriptive message (e.g. about the unsupported curve) instead of the class name.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kotlin/openID4VP/src/commonTest/kotlin/io/mosip/openID4VP/jwt/jwe/encryption/EncryptionProviderTest.kt`
around lines 57 - 69, Update the `EncryptionProviderTest` case for
`getEncrypter` so it no longer expects the exception message to be the class
name `EncryptionProvider`. After fixing the swapped `JweEncryptionFailure`
arguments in `EncryptionProvider.kt`, assert the real descriptive message for
the unsupported EC curve path instead, while keeping the same `INVALID_REQUEST`
error code. Use the existing `assertOpenId4VPException` helper and the
`getEncrypter`/`JweEncryptionFailure` symbols to locate the affected assertion.

kotlin/openID4VP/src/commonMain/kotlin/io/mosip/openID4VP/authorizationResponse/AuthorizationResponse.kt (1)

50-66: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Consider deriving toJsonEncodedMap() from toMap() to avoid duplicated branching.

Both functions branch on the same sealed subtypes with nearly identical shape. Not urgent, but worth consolidating to avoid the two implementations drifting.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kotlin/openID4VP/src/commonMain/kotlin/io/mosip/openID4VP/authorizationResponse/AuthorizationResponse.kt`
around lines 50 - 66, The branching logic for AuthorizationResponse
serialization is duplicated between toMap() and toJsonEncodedMap(), which risks
the two implementations drifting. Refactor toJsonEncodedMap() to derive its
payload from toMap() in AuthorizationResponse, and keep the subtype handling in
one place so both PresentationExchange and Dcql stay consistent. Use the
existing toMap() and AuthorizationResponse sealed subclasses as the single
source of truth, and only apply JSON-encoding-specific transformation after that
shared map is built.

kotlin/openID4VP/src/commonMain/kotlin/io/mosip/openID4VP/jwt/jwe/JWEHandler.kt (1)

35-46: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Broad catch (exception: Exception) re-wraps already-typed OpenID4VPExceptions (e.g. UnsupportedKeyExchangeAlgorithm, JweEncryptionFailure from EncryptionProvider.getEncrypter).

EncryptionProvider.getEncrypter(publicKey) is called inside this try block and can throw JweEncryptionFailure or UnsupportedKeyExchangeAlgorithm. Both get caught by the generic Exception handler and re-wrapped into a new JweEncryptionFailure, losing the original exception type (only the message text is preserved, nested with a "JWE Encryption failed :" prefix). Callers/tests that pattern-match on the specific exception subtype downstream of this call path would no longer see it.

♻️ Suggested fix — rethrow already-typed exceptions as-is

             val encrypter = EncryptionProvider.getEncrypter(publicKey)
             val jweObject = JWEObject(header, Payload(payload))
             jweObject.encrypt(encrypter)

             return jweObject.serialize()
+        } catch (exception: OpenID4VPExceptions) {
+            throw exception
         } catch (exception: Exception) {
             throw OpenID4VPExceptions.JweEncryptionFailure(
                 "JWE Encryption failed : " + (exception.message ?: "Unknown error"),
                 className,
                 exception
             )
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kotlin/openID4VP/src/commonMain/kotlin/io/mosip/openID4VP/jwt/jwe/JWEHandler.kt`
around lines 35 - 46, In JWEHandler.encrypt, the broad catch block is
re-wrapping exceptions that are already OpenID4VPExceptions, which hides the
original subtype. Update the catch logic so EncryptionProvider.getEncrypter and
jweObject.encrypt failures that already throw OpenID4VPExceptions (such as
UnsupportedKeyExchangeAlgorithm and JweEncryptionFailure) are rethrown
unchanged. Keep only unexpected exceptions wrapped into JweEncryptionFailure,
preserving the current className context where needed.

kotlin/openID4VP/src/commonMain/kotlin/io/mosip/openID4VP/jwt/jwe/encryption/EncryptionProvider.kt (1)

77-90: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Missing y coordinate throws UnsupportedKeyExchangeAlgorithm instead of a message describing the actual problem.

Throwing UnsupportedKeyExchangeAlgorithm (message: "Required Key exchange algorithm is not supported") for a missing y coordinate is misleading — the algorithm/key exchange type is fine; the JWK is simply malformed/incomplete. A JweEncryptionFailure with a specific message (e.g. "EC key is missing required 'y' coordinate") would aid debugging conformance-test decryption failures, which is a stated goal of this PR.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kotlin/openID4VP/src/commonMain/kotlin/io/mosip/openID4VP/jwt/jwe/encryption/EncryptionProvider.kt`
around lines 77 - 90, The `getPublicEcKey` helper is throwing
`UnsupportedKeyExchangeAlgorithm` when `jwk.y` is missing, which masks the real
issue. Update this branch in `EncryptionProvider` to fail with a
`JweEncryptionFailure` (or the project’s equivalent encryption error) and a
clear message that the EC JWK is incomplete, explicitly mentioning the missing
`y` coordinate. Keep the rest of `getPublicEcKey` unchanged so valid `Curve`,
`jwk.x`, `jwk.kid`, `jwk.alg`, and `jwk.use` handling still works.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes